In the field of printing, it is generally desirable to maximize not just printing quality, but also printing speed at a printer. Customers tend to dislike any delay that occurs between sending a print job to a printer, and receiving the printed sheets of the print job. Therefore, printer manufacturers strive to optimize not only the physical printing speed of marking engines that mark printed sheets, but also the processing speed of devices that prepare incoming print jobs for printing by interpreting and rasterizing them.
In order to increase the processing speed for incoming print data, print controllers often include multiple Raster Image Processors (RIPs) that operate in parallel. The print controller splits the incoming print job into segments of data (e.g., logical pages), and sends the segments to the parallel RIPs for interpretation and rasterization. For example, each of the parallel RIPs may interpret incoming segments by generating a display list or other instructions for marking pels on a page. The parallel RIPs may further rasterize/render the segment by placing pels in a bitmap with an appropriate mark/color based upon the generated display list.
Processing incoming print data using parallel RIPs is generally desirable because it increases the speed at which a print job may be interpreted and rasterized, which is often the most time consuming part of printing an incoming job. Unfortunately, when print jobs are encoded according to a page description language (e.g., PostScript), a segment may refer to a page element (e.g., pictures, headers, footers, etc.) that has been defined in another segment. For example, in a two-page job, the first logical page may define an image, and the second logical page may include a pointer to the image defined on the first page. Furthermore, each logical page may be sent to a different parallel RIP. In these cases, it is not possible to interpret or rasterize the second logical page without looking to the first logical page, which defines the page element. However, because the parallel RIP processing the second logical page has not interpreted the first logical page, it is incapable of interpreting the page element. Thus, the parallel RIP reports a processing error. This type of error is generally referred to as a dependency error.
In the present state of the art, a print controller detecting such an error from a parallel RIP aborts the print job, and indicates to the host that the print job contains an error. Thus, no printing of the print job occurs. This is generally undesirable to the end user, because the end user may not be capable of recreating a print job without the dependency error. Even assuming that the print job can be recreated without dependency errors and sent for printing a second time, regenerating the print job creates a significant and undesirable delay in the printing process.